IBIS Macromodel Task Group Meeting date: 30 May 2017 Members (asterisk for those attending): ANSYS: * Dan Dvorscak * Curtis Clark Broadcom (Avago): Xingdong Dai Bob Miller Cadence Design Systems: * Ambrish Varma Brad Brim Kumar Keshavan * Ken Willis eASIC: David Banas Marc Kowalski Ericsson: Anders Ekholm GlobalFoundries: Steve Parker IBM Luis Armenta Trevor Timpane Intel: * Michael Mirmak Keysight Technologies: * Fangyi Rao Radek Biernacki Ming Yan Maxim Integrated Products: Hassan Rafat Mentor, A Siemens Business: John Angulo * Arpad Muranyi Micron Technology: Randy Wolff Justin Butterfield SiSoft: * Walter Katz Todd Westerhoff * Mike LaBonte Synopsys: Rita Horner Kevin Li Teraspeed Consulting Group: Scott McMorrow Teraspeed Labs: * Bob Ross TI: Alfred Chong The meeting was led by Arpad Muranyi. -------------------------------------------------------------------------------- Opens: - None. ------------- Review of ARs: - None. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: - Arpad: Does anyone have any comments or corrections? [none] - Ambrish: Motion to approve the minutes. - Walter: Second. - Arpad: Anyone opposed? [none] ------------- New Discussion: BIRD 166.3 Redriver Flow: - Arpad: I was disappointed when we couldn't come to agreement last week. - I've thought about these issues, and I had a long email conversation with Curtis. I've crystalized my thoughts and prepared a high level summary I'd like to review. - [sharing "Summary of the AMI Redriver flow problem and BIRD 166"] - slide 1 - Current AMI flow in IBIS v6.1 - Familiar channel drawing Walter has reviewed. - Channels treated independently and IRs convolved afterwards. - Problem: Optimizations in channel 2's Tx or Rx Init() are unaware of channel 1. - slide 2 - Proposed Simple Fix - Proposed simple fix was to move the convolution to prior to calling Rx or Tx Init() in channel 2. - Problem was, it could break other flow cases. - Which cases? - slide 3 - Introduce "self IR" terminology for this discussion. - slide 4 - Broken cases - Doing the convolution sooner, we lose the self IR of the downstream channel(s). - May require de-convolution for the GetWave() flow if any model does not have a GetWave(). - Fangyi demonstrated an example where this causes problems and can amplify non-linearities, crosstalk and noise. - Crosstalk needs self IR? - slide 5 - Working Cases. - Init-only models (with or without optimization) work with the proposed "early convolution" fix. - Is crosstalk broken without self IR? - GetWave Only models work. - They don't use the output of the Init functions. - Dual models work - For the reasons given above for the Init Only and GetWave Only. - slide 6 - We wouldn't have these problems if: - If we never allowed models with GetWave_Exists = false. - If we never had to do crosstalk simulations? - We did not optimize in the Init() function, ever, not even for the statistical flow. - We didn't want to have our cake and eat it too :-) - slide 7 - Possible solutions - Add additional IRs to the Init() function processing (Fangyi's proposal). - Consider executing the Init() function multiple times to get the "self IR" and or "cumulative IR" as needed. - Consider independent/different Init() flows for the statistical and time domain (bit-by-bit) simulations. - Consider eliminating mixed-model cases. - May not be an option for some model makers. - Discussion: Walter said Arpad's presentation was an excellent summary of the issues. He noted that the only thing he disagreed with was any statement that crosstalk was a particular problem. Walter stated that crosstalk in a pure statistical flow does not require the "self IR". In the time domain flow, it needs the "self IR" in the same mixed mode cases that are a problem anyway. - Walter: I'd like to expand on the calling Init() multiple times suggestion. - Call Init() the first time with everything in the IR, so it can optimize. - The model should report what its optimized settings are. - Resimulate, and only feed Init() the self-IR but pass it the optimized settings from the first call to Init(). - This would be painful for the EDA tool to automate, but could be done now with manual intervention from the user. - - Walter: The starting point for these discussions was the assumption that all the models have Init_Returns_Impulse = true. - All models have Init_Returns_Impulse = true, or statistical flow is dead. - Pure Init() flow is corrected by BIRD 166. - Second case - time domain flow if any models are missing GetWave(). - May require deconvolution. - Yes, deconvolution if DFE is involved is problematic. - I agree with Fangyi's argument. - I go back to today's spec, and I think we may say to ignore all GetWave() if any model is missing GetWave(). - I like Fangyi's proposed solution. - I like it for many reasons, not just redriver flow. - Ken: I've also been thinking about this. - There is some precedent for this type of issue. - There has always been a certain amount of scalability and different levels of detail. - You have simple Ramp vs. v(t) curves. - I/V curves vs. [External Model]. - Different types of package parasitics. - It's never assumed that every model is going to work for everything. - Here we seem to be going to great lengths to make everything do everything correctly. - Arpad: The difference here is that if one model breaks the chain (for example one model has no GetWave()) then all the rest of the models suffer. - Whereas, if one has a weaker package parasitics model, it doesn't affect the accuracy of other package models used in the simulation. - Ken: Init Only vs. GetWave is a similar issue. - One is coarser and one provides finer detail. - Walter: I agree. - What we are trying to do here is identify when you've made a model that works with everything and when you've made one that has lesser features. - We are trying to lay out for the user and model maker what the limitations are. - Ken: We could define a top-level description in the spec. - We could just define the super-set cases where you know the models contain enough to do everything, and everything is expected to work, and tell people how to stay on that path. - Arpad: But taking your comment in the context of this discussion: - Are you saying that if we fixed the Init() flow to allow the statistical flow to work that is enough? - That's what BIRD 166 started with. - It was only when we discussed that proposal and the cases where you had a GetWave() missing in the time domain flow that we ran into trouble. - Are you saying we should not try to have a time domain flow solution that works for a model without GetWave()? Would you instead say that it's the fault of the model that doesn't have GetWave(), not a flow issue? - Walter: Allow me to summarize (for Ken): - We just say there are three kinds of models (Init Only, GetWave Only, Dual). - The only flows we are going to document are: - 1. All the models have Init_Returns_Impulse = true (statistical flow). - 2. All the models have GetWave_Exists = true (time domain flow). - We can say that there are other flows that are valid, some of which require sophisticated analysis, but these are all that we document. - But, changing the subject a bit, what do we want to accomplish in today's meeting? - Walter: Yes, in IBIS 7.1 we should address this in a very serious way. - I like Fangyi's solution (additional IR outputs from Init()). - We should rewrite the flows and describe two flows: - 1. Every model has Init_Returns_Impulse = True (statistical flow). - 2. Every model has GetWave_Exists = True, or its Init() provides the additional IRs from Fangyi's proposal. (time domain flow) - For now, we have to decide if we are going to move forward with BIRD 166.2. - Ambrish: Which version of BIRD 166 are we talking about? - Walter: (referring back to the drawing in slide 1 of Arpad's presentation) We are back to the one that convolves before the Rx2 Init(). - At one point I'd changed that convolution to before the Tx2 Init(), but Fangyi had an issue with that. - So now it's back to before Rx2 Init(). So we do have an issue if the Tx2 Init() wanted to optimize, but otherwise it solves the statistical flow. - If any of the models is missing GetWave(), then the only "time domain" flow it would support is convolving the output of Rx2 Init() with the digital stimulus for Tx1. - Arpad: In the change from 5.0 to 5.1 we changed that convolution. - (Single channel flow): If the Rx had no GetWave(), then the output of Rx Init() used to be convolved with the digital stimulus prior to calling the Tx GetWave(). But for 5.1 we decided that was wrong, and we said to convolve the output of Rx Init() with the output of Tx GetWave(). - Walter: I was only referring to the case where there are no GetWaves (because of the fact that in BIRD 166 I now say that for a time domain flow if any of the models has no GetWave() then you ignore all GetWaves). So you simply convolve the digital stimulus (input to Tx1) with the output of Rx2 Init(). - Discussion: Walter again described his interpretation of the interplay between the redriver flow section and its reference back to the single channel flow. He referred to the section of the single channel flow that described potential issues if the Tx had GetWave() and the Rx did not. In this case you could encounter problems with double counting the Tx equalization if the output of Tx GetWave() were convolved with the output of Rx Init(). The spec. noted one possible way to deal with the issue would be for the EDA tool to "not utilize the Tx AMI_GetWave functionality..." (pg. 178 IBIS 6.1). Walter extended this concept to redrivers by saying that if any model were lacking a GetWave() then then none should be used. He said this was the only clean and clear way to describe the time domain flow unless every model had a GetWave(). Fangyi again objected to this interpretation, and said the section Walter referred to would only imply that one channel in the redriver flow (say, the downstream channel) would have to ignore GetWave(), not all of the channels in the redriver simulation. Walter said he thought BIRD 166.2 is correct when all the models have Init_Returns_Impulse = true (statistical flow). Fangyi agreed it worked for the statistical flow. Walter said BIRD 166.2 is correct in the time domain flow if every model has GetWave_Exists = true. Fangyi agreed. Walter also noted that the flow in BIRD 166.2 is correct if all the models are dual models. Ambrish expressed concern about the convolution being done after the output of Tx2 Init(). Walter agreed that he preferred to do it before Tx2 Init(), but others had objected. Ambrish said the supposition that Tx2 Init() didn't need to optimize was a problem, and noted that he had developed optimizing Tx models. Fangyi noted that BIRD 166's assumption that you ignore all GetWaves under certain conditions (if any model did not have a GetWave()) would be a problem for Ambrish's GetWave() only models. Arpad showed a section of a previous meeting's minutes that captured Fangyi's objection to performing the convolution prior to Tx2 Init(). Imagine a time domain flow in which the Tx2 model provides no GetWave(). During GetWave() processing, the EDA tool needs an IR that captures only Tx2 and the downstream channel. This is used to propagate the output of Rx1's GetWave() to Rx2's GetWave(). Ambrish asked if the BIRD modified the GetWave() flow at all. Arpad said that if we kept away from the GetWave() flow and only wanted to modify the pure statistical flow then there might be no issue with moving the convolution to before Tx2 Init(). Curtis said this was what had led to one of the discussion points in the email exchange he had with Arpad. Curtis noted that Walter's original BIRD 166 proposal had only modified the statistical flow section of the redriver text. He noted that the spec contained entirely independent statistical flow and time domain flow sections, each of which independently described the Init() flow portion. Curtis said he had therefore been confused when Fangyi raised time domain flow based objections to Walter's original proposal, given that the original proposal only modified the statistical flow. Curtis noted that in BIRD 166.2 Walter had added the same Init() flow changes to the time domain flow. Curtis said he had made this suggestion to Walter, but that he had made the suggestion only based on concern about models of the type provided by Bob Miller (models that provide a GetWave() for time domain, but do their optimization in Init() and therefore require the entirety of upstream information at Init() time). Curtis said he had not made the suggestion based on any thought that the Init() flow portion of the statistical and time domain flows had to remain identical. Curtis said Arpad had said in their email discussion that he thought the goal of the spec, based on discussions from years ago, had been to keep the Init() flow identical for the statistical and time domain flow sections. Walter noted that he had made the change Curtis suggested and modified the time domain flow as well, but he had in fact done it because he wanted to keep the Init() flow portions identical. He agreed with Arpad that this had been the goal of the spec, and he intended to keep the Init() flows identical. He had viewed Curtis' suggestion as correcting an editorial oversight. Fangyi and Ambrish still expressed concern about any change in interpretation from BIRD 166 that went away from the idea of handling the simulation channel- by-channel, particularly the change that would ignore all GetWaves if any model did not have GetWave. Walter said he had taken BIRD 166 as far as he could and, barring any new suggestions for modifying it, he felt we should simply vote at some point on whether to move it to the Open Forum. Walter noted that he would not be available for the next two ATM meetings. - Arpad: Thank you all for joining. ------------- Next meeting: 06 June 2017 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives